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NEEDLE & ROSENBERG, P.C. 
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Sir: 

Prior to the issuance of an Office Action pertaining to the above-identified patent 
application, please enter the following preliminary amendment and consider the following 
remarks. 

IN THE SPECIFICATION 
On page 1 of the specification, before the first paragraph, please insert the following: 



~ The present application is a 35 U.S.C. § 371 national phase application from, and claims 
priority to, international application PCTAJSOO/13716, filed May 17, 2000 (published under PCX 
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Article 21(2) in English), which claims priority to U.S. International Application No. 
PCT/USOO/09089, filed April 6, 2000, which application is hereby incorporated herein in their 
entirety.- 

REMARKS 

The specification is amended herein to update the priority claim for this application. It is 
believed that no new matter has been added by this amendment, and applicants respectfully 
request entry of same into the present application. 



No fee is believed due; however, the Commissioner is hereby authorized to charge any 
additional fees which may be required, or credit any overpayment to Deposit Account No. 
14-0629. 
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SYSTEM AND METHO D FOR AUTOMATED 
TRACKING OF FINANCIAL TAUNTS ACTIONS- 



CROSS-REFERENCE TO RELATED APPLICATION 

This application is a continuation-in-part of U.S. Application Serial No. 
09/271,522, filed March 18, 1999, the entirety of which is incorporated herein by 
reference. 

FIELD OF THE INVENTION 

This invention generally relates to a system and method of automated input and 
tracking of financial transactions useful for generating financial reports, such as budget 
reports and expense reports, for end users. 

BACKGROUND OF THE INVENTION 

Electronic financial information is prevalent in the economy due to the 
increasing use of automated transactions, credit and debit card services, and e- 
commerce conducted across the Internet. These transactions are typically made by 
electronic payment instruments such as a credit, charge or debit type card that utilize 
electronic means for transfer of payment, often at the point of sale. Other ways to make 
purchases are with personal (paper or electronic) checks. 

Both consumers and business often desire to track financial items (income and 
expenses) and generate user reports, such as budget reports, expense reports, etc., in 
order to monitor financial transactions. Most personal or business financial systems 
currently available require tiie user to manually input data in order to generate 
meaningfiil reports. This is time consuming and laborious. 

On the other hand, credit/debit and charge card companies and merchants 
provide details about the transactions a user makes. This transaction detail comes in the 
form of monthly statements or data that can be downloaded by the user. The user still 
must manually enter the data into the appropriate report fields in order to generate 
usefiil reports. In addition, most financial institutions (banks or brokerage houses) 
provide data to users ttiat details the checks written, deposits made and cash withdrawn. 
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Accordingly, it would be desirable to provide a system and method that would 
allow a user to receive an automated report for transactions conducted with that user's 
instrumaits by the use of electronic methods, thus reducing effort and inaccuracy 
associated with manual transaction report generation and reconciliation. It is to the 
5 provision of such an improved system and method that the present invention is 
primarily directed. 

SUMMARY OF THE INVENTION 

Briefly, the present invention is directed to a system and method for 

10 automatically tracking and presenting fibtiancial activity for an end user. Transaction 
data are electronically received from at least one transaction data source, the transaction 
data associated with an account of an end user. End users may select which of their 
various credit card, debit card, checldng accoxmt, etc., are to be part of the service. The 
transaction data are automatically sorted into categories based on identifier information 

15 in or associated with the transaction data. In one embodiment, the transaction data 
includes merchant type identifiers such as, for example, standard industry codes 
("SIC") indicative of the nature of the financial transactions. In another embodiment, 
the transaction data includes item identifier information that is used to automatically 
categorize each item of a multi-item transaction, e.g., receipt details from a merchant. 

20 The account service provider receives user transaction data from one or more 

transaction data sources according to the instructions made by an end user. In this way, 
the user can integrate some or all of his/her financial transactions into meaningfiil 
reports. A variety of other financial resources and comparison features are provided 
that are also available to end users. 

25 The above and other objects and advantages of the present invention will 

become more readily apparent when reference is made to the following description 
taken in conjunction with the accompanying drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a block diagram of the system according to the present invention. 
FIG. 2 is a block diagram of the account service provider according to the 
5 present invention. 

FIGs. 3 and 4 are diagrams showing examples of category-coded checks useful 
in connection with the present invention. 

FIG. 5 is a flow chart depicting the generation of transaction(s) by an end user 
credifdebit card transaction. 
10 FIG. 6 is a diagram pictorially representing the overall process according to the 

present invention and an example of a user report. 

FIG. 7 is a flow chart illustrating the steps of processing transaction data 
according to the present invention. 

FIGs. 8 and 9 are diagrams illustrating how a user may manually enter and 
15 categorize transaction data that the ASP does not otherwise automatically categorize. 

FIG. 10 is a flow chart illustrating a process for prompting users to manually 
categorize transaction data and for seeking permission from end users to receive 
detailed transaction data from a merchant. 

FIG. 1 1 is a diagram depicting a message that is provided to an end user in 
20 association with the process shown in FIG. 10. 

FIG. 12 is an example of a screen displayed by the account service provider that 
shows budget comparison information for an end user. 

FIG. 13 is an example of a screen displayed by the account service provider that 
shows category information by month. 
25 FIG. 14 is an example of a screen displayed by the account service provider that 

graphically compares expenses by category from month to month. 

FIGs. 15 and 16 are examples of screens displayed by the account service 
provider that compares budget information for an end user with information for an 
average budget. 
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FIG. 17 is an example of a screen displayed by the account service provider that 
shows a calendar for recording and scheduling transactions. 



DETAILED DESCRIPTION OF THE INVENTION 

5 Referring to FIG. 1, the present invention will be described. According to the 

present invention, an account service provider (ASP) 10 interfaces vnth one or more 
end users via user devices 12 and a plurality of transaction data soiu-ces. User device 12 
may be a personal computer (PC), Internet-capable wireless communication device, 
web browser or any other device capable of communicating with the ASP 10 and 

10 performing basic graphic display or voice communication, computation and 

communication functions. Each end user generates financial transactions associated 
with one or more financial accounts. A web browser device is an example of a device 
that may be used by an end user to communicate with the ASP 10. 

The term "user transaction data" is meant to refer to the transaction data 

15 associated with any account fix)m which an end user may spend money or into which an 
end user may deposit or receive financial credits. User transaction data includes, but is 
not limited to, transaction data associated vnth credit card accounts, debit/ATM card 
accounts, checking (paper and electronic) accoimts, savings accounts, investment 
accounts, Internet accoimts, user transaction recording devices (such as "smart cards" or 

20 hand-held computer devices, such as Palm® computing devices), that store transaction 
information. 

Transaction data sources include card institutions 20, financial institutions 22, 
processors 24, merchants 26 and user transaction recording devices 28. Examples of 
card institutions 20 are credit card issuers, charge card issuers, debit card issuers, etc. 

25 Examples of financial institutions 22 are banks and/or brokerage firms that manage 
checking and savings accounts, investment accounts, etc. Processors 24 are, for 
example, transaction processors for card institutions 20, financial institutions 22, and 
merchants 26 as well as check processors for card institutions 20, financial institutions 
22 and any other entity against which checks are drawn. In addition, processors 24 

30 includes entities that receive user transaction data at the request or authorization of an 
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end user, such as on-line or Internet banking or transaction data services provided by 
Yahoo!® and Intuit®, AOL®, Microsoft Money®, etc. Another example of a 
processor is a wireless network service provider that receives transaction data via 
wireless transmissions from a user transaction recording device 28, Merchants 26 are 
5 the entities from which users make transactions to purchase goods or services, receive 
credits for returns and exchanges, etc. 

The ASP 10 also tracks non-transaction type data, such as account balance 
information, account posting information, etc. 

End users communicate with the ASP 10 through one or more communication 

10 network(s). Similarly, the ASP 10 receives information from the transaction data 

sources via the communication network(s) 30. The commimication network(s) 30 is, 
for example, the Intemet, and/or any a combination of other wired and wireless 
networks. In other instances, the ASP 10 may have a dedicated data feed with a 
particular transaction data source, 

15 The end users are individuals or business entities (small or large) and each end 

user has an account with the ASP 10. When enrolling for service with the ASP 10, the 
end user identifies to the ASP 10 the transaction data sources for user transaction data 
to be automatically tracked and merged into a imified user report. As used hereinafter, 
the term "user report" is meant to include budget reports, expaise reports (personal or 

20 busmess type) or other types of spending reports, including, but not Umited to, profit 
and loss reports. 

The end user provides information about the transaction data sources to be used 
by the ASP 10, such as transaction data from credit, debit, charge card, paper and/or 
electronic checking, investment and other accounts that the user wishes to be part of the 

25 service. The end user can be enrolled either directly with the ASP 10 or indirectly in 
conjimction with a benefit or service provider, including card institutions, financial 
institutions, processors, merchants, Intemet portals, etc. The ASP 10 assigns a service 
accoimt number or other identifier unique to each end user. The end user may also mail 
a signed registration form with other related information to the ASP 10 or related 

30 institution as noted above. 
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The ASP 10 can be a stand-alone entity that end users subscribe to, or the 
functions tibat are performed by the ASP 10 can be integrated into the functions and 
services provided by card institutions 20, financial institutions 22, processors 24 and/or 
merchants 26 or other companies iucludiug Internet portals. 
5 Turning now to FIG. 2, the ASP 1 0 is shown in more detail. The ASP 1 0 

comprises computing equipment 110, data storage equipment 120 and a communication 
interface 130. The computing equipment 110 consists of one or more PCs, servers, 
computers or other computing equipment or device that execute(s) the processes 
described herein. Transaction data associated with ©ad users is stored in a database 

10 residing on the data storage equipment 120. The data storage equipment may be any 
suitable large storage device or system known in the art. The communication interface 
device 130 is coupled to a communication network(s) and comprises a communication 
interface, such as for example, a modem bank, an ISDN device, DSL modem(s), 
vwreless networks, etc. 

15 FIGs. 3 and 4 illustrate category code checks useful in connection with the 

present invention. The category-coded checks are either paper or electronic and may be 
used by an end user that has a checking accoimt that is either serviced by ttie ASP or by 
any financial check processor that processes end user checks. Category coded checks 
enable the ASP to automatically sort a purchase paid for by the check. FIG. 3 shows an 

20 example of a category-coded check 200 tiiat has a plurality of boxes 210 labeled with a 
corresponding category. When making a payment with the check 200, the end user 
checks a box that corresponds to the category for which Hhe payment is made. FIG. 4 
shows a category-coded check 300 that includes code block 3 10 in which an end user 
writes an alphanumeric code corresponding to the appropriate category. The end user 

25 selects the proper code from a list of alphanumeric codes 320 listed on the face of the 
check, the checkbook register or otherwise provided to the end user. Category-coded 
checks like those shown in FIGs, 3 and 4 enable the ASP to automatically sort 
purchases/payments into the appropriate category for user report generation. In 
addition, as described further hereinafter, category-coded checks assist the ASP in 
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processing check payments to avoid double counting of charge card payments for user 
report purposes. 

FIG. 5 illustrates tiie basic process by which transaction data is generated when 
a user conducts a transaction. In step 40, the end user conducts transaction(s), such as a 
5 purchase, dqposit, credit, etc. The purchase may be by credit card, debit card, category- 
coded check, electronic check, cash, smart card, etc. Transaction data associated with 
the transaction is generated in step 42. For example, if the transaction was the purchase 
of a good or service from a merchant with a credit, debit or charge card, then the 
transaction data gaaerated will include a merchant type identifier, such as a standard 

10 industry classification (SIC) code. The merchant type identifier is used by tiie ASP 1 0 
to identify and classify the purchase of goods or services into report categories. This 
transaction data may also include an item type identifier that identifies the particular 
item purchased. This is particularly useful to categorize items in a multi-item purchase 
transaction. Next, in step 44, the transaction data is transmitted or downloaded to the 

15 ASP 10 tibrough one of a variety of communication means as already described from a 
transaction data source. The ASP 10 will know which transaction data source to 
receive information from on behalf of an end user based on the transaction data sources 
identified by an end user at enrollment or any time when a user adds, deletes or 
modifies a transaction data source. 

20 The processing of user transaction data wiU be described in more detail with 

reference to FIGs. 6 and 7, in conjxmction with FIG. 1. FIG. 6 shows the operation of 
tiie ASP at a higher operational level and FIG. 7 shows more detail aspects of the 
ASP's operation. 

Referring first to FIG. 6, in general terms, the ASP receives transaction data 
25 from one or more transaction data sources, sorts the transaction data into categories (if 
information in or associated with the transaction data allows the ASP to do so), updates 
user reports based on new transaction data, and displays user reports, such as a budget 
report or expense report. 

Turning now to FIG. 7, the ASP 10 receives transaction data from one or more 
30 transaction data sources (card institution 20, financial institution 22, processor 24, 
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merchants 26 or user transaction recording device 28) in step 50. The ASP 10 then 
segregates the transaction data, if necessary, and stores the transaction data associated 
with a corresponding user account for each end user in step 52. The storage of the 
segregated data can be in a raw form or in a stored database, electronic spreadsheet or 
5 other electronic format in a database of transaction data for an end user. Associated 
with or contained in some transaction data is an identifier that allows the ASP 10 to 
automatically sort the transaction information into an appropriate category; the 
identifier may be one field of information contained in the transaction data or may be 
appended to information in a transaction record. In step 54, the newly received 
10 transactions are processed according to one or more of a variety of criteria. After the 
transaction data is processed, one or more user report(s) for tiiat end user is updated in 
step 56. The user report is useful to show the user historical financial information 
useful in financial analysis, budgeting, personal finance planning, business finance 
planning, etc. 

15 The types of processing that may occur in step 54 will be now e5si)lained. 

According to one aspect of the invention, transaction data received by the ASP that is 
received fi-om a transaction data source is automatically categorized into one of several 
spending or budget categories. There is an initial set of categories that are pre-assigned 
by the ASP 10 to all existing merchant type identifiers and by default, a transaction is 

20 automatically categorized according to tiiat preset assignment. However, a user has the 
option of altering a pre-assigned relationship for certain transactions to change the 
corresponding spending or budget category. For example, the merchant type identifier 
(such as an SIC code) associated with a (credit card, debit card, etc.) transaction is used 
to categorize the transaction. It is worthy to again note that an end user may have 

25 multiple sources of data (different credit card accounts, debit card accoimts, checking 
accounts, savings accounts, etc.) from which transaction data is received and processed. 

Still referring to FIG. 7, another type of processing will be described to 
categorize individual items of a multi-item transaction. For example, if an end user 
shops at K-Mart, he/she makes a purchase in the automotive department and another 

30 purchase in the clothing department on the same or different transaction. Another 
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example is the multiple types of spending a user makes at a hotel (room service/meals, 
lodging, cleaning, etc.) If the detail transaction data from the receipt at the merchant is 
made available to the ASP 10, then the ASP 10 is able to delineate specific charges by 
category wittiin a specific retailer by an item identifier or by merchant department code. 

5 This allows for categorization of charges at a more micro level than simply capturing 
the amount of the total charge from the merchant by merchant type identifier. 

Accordingly, at step 60, detailed elecfronic receipt type data from a merchant 
(or other source) is received by the ASP 10 that includes item type identifiers and 
corresponding amounts for each item in a multi-item transaction. The received 

10 information in step 60 is similar to an electronic receipt and it contains the same 

information typically included on a cash register receipt, such as item description, item 
identifier type code, department code, corresponding item amount, subtotal, tax and 
total amount. This data is obtained through a data feed that the ASP 10 negotiates for 
from a merchant or from a processor 24 that manages this information on behalf of a 

15 merchant. The detailed data may be sent through the communication network(s) via 
dedicated modem connection, Intemet, wireless network, or other means known in the 
art. 

In step 62, the ASP 10 matches the detailed transaction information to the 
corresponding end user (based on the credit card account number) and determines 

20 whether a corresponding "general" transaction record appears in that user's transaction 
data which would have been received from a credit card processor or other financial 
institution. For example, it is possible that before the detailed transaction information 
is received by the ASP 10, a more generalized transaction has already been recorded 
that would include the same information as the detailed information. If so, then in step 

25 64 that "general" transaction (which was not categorized at the micro level) is replaced 
with transaction information for each item that was purchased. This avoids double 
counting of the transaction(s). On the other hand, if no corresponding "general" 
transaction is present, in step 64, the tiansaction information for each item is stored as if 
a separate transaction. In essence, the ASP detects when transaction data received from 
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two or more transaction data sources references tiie same data items for an end user so 
as not to double count the same transaction data. 

From step 64, the process continues to step 54 where the more detailed 
transaction information is processed. Specifically, in step 54, the detailed transaction 

5 information is categorized based on an item identifier (product code, department code, 
etc.) for that item. The user report information is updated in step 56. 

A further use of the electronic receipt received by the ASP for a user is to 
e^qpedite user report processing. Specifically, the electronic receipt (embodied as a data 
file) can be transmitted to the end user (via email or otherwise downloaded). The user 

10 can review the items on the electronic receipt, complete an electronic user data input 
report based on the items in the receipt, and send the electronic receipt with the 
completed electronic user report for approval and processing. The electronic receipt 
also may be sent to a printer to be printed, if necessary. One use of the electronic 
receipt is to facilitate processing of expense reports. See co-pending U.S. Application 

15 No. 09/271,522, filed March 18, 1999, referred to above, for fiuHier details on 
automated expense reporting. 

With reference to FIGs. 8 and 9, another processing feature that occurs ia step 
54 is the automatic reconciliation of user report iofoimation to detail transaction 
information provided by a transaction data source. Data in the user report is compared 
to some or all of the transaction information provided by a merchant or other source of 
that end user. A transaction that has not beeti categorized is flagged, so that the user 
can manually categorize it. This is useful when the transaction data received by the 
ASP does not include identifier information to enable the ASP to automatically sort it. 
Examples of such transaction data is data resulting from tiansaction made by regular 
checks, cash purchases, some charge card transactions (whereby the merchant type 
identifier or item type identifier is not present) or any other transaction that does not 
include identifier information that the ASP can use to automatically categorize the 
transaction. One method of doing this involves notifying an end user when a 
transaction has not been automatically sorted in order to allow the end user to manually 
add it to the report. The ASP provides notification by, for example, sending an email 
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message to an end user or displaying a message on a web page. The end user can edit 
tile message to include category information to enable the transaction to be sorted 
according to information provided by the end user, and respond to the email message 
back to the ASP. In another method, the ASP displays a message in a web page to the 
end user during the end user's connection session with the ASP. FIGs. 8 and 9 are 
exemplary user interface screens that show how the ASP may display to the end user 
information about transactions that have not been categorized in order to allow the end 
user to manually categorize them. 

Referring back to FIG. 7, still another processing feature that optionally occurs 
in step 54 is tracking of deposits into an account of an end user. Deposits/credits are 
contained in statement data transmitted from a financial institution to the ASP 10. For 
example if an end user makes deposits into a checking, savings, investment, etc., 
5 account, the ASP 10 will recognize the deposits and enter categorize them as income. 
The ability to track deposits has particular utility in automatically determining whether 
a user has been reimbursed by an employer for authorized business related credit card 
transactions, for example. 

Another type of processing occurs in step 54 when transaction data provided to 
10 the ASP is from (paper or electronic) category-coded checks such as those shown in 
FIGs. 3 and 4. The category information identified on the face of a category-coded 
check is recorded with the fransaction data by a check processor for the bank, 
investment company, etc., from which the check is drawn and processed. The check 
processor generates a corresponding digital category code that is transmitted to the ASP 
15 together with other transaction data associated with the category-coded check 
transaction. The ASP uses the digital category coded to automatically sort the 
transaction into the appropriate category for that end ULser. 

Yet another processing feature that optionally occurs in step 54 is tracking data 
automatically entered into a user report to prevent double counting of data from two or 
20 more data sources. For example, an end user pays for a credit card bill with a check. 
The expenses on the credit card are processed into the user report as explained above. 
Subsequently, a user pays the credit card bill with a check and the check is entered into 
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the user report from any other transaction data source. However, since the charge card 
transaction detail would have already been processed and accounted for in the user 
report, the dollar amount paid for by the check would be double counted in the user 
report. The ASP 10 prevents double counting if some or all of the charge card data has 

5 akeady been categorized and entered into a user report by matching the charge card 
transaction data to the payment of the charge card bill based on, for example, a 
combination of one or more of: the charge card payment due date, the "credit card" 
category indicated on a category-coded check, transaction identifier number if coded or 
otherwise identified on the check that pays that charge card bill, dollar amount, 

10 merchant identifier and/or merchant name. These are only examples of the manner in 
which the ASP determines a match. It should be understood that the source of the data 
for the charge card transactions may be different from the source of the data for the 
bank statement information necessary to detect and avoid double counting of a 
transaction. 

15 The foregoing description relates to processing of "on-line" type transactions. 

Another type of transaction that can be uploaded to the ASP 10 for processing and 
inclusion in a user report is an "ofF-hne" transaction. An example of a device from 
which the ASP 10 receives off-line transaction data is the user transaction recording 
device 28 shown in FIG. 1. For example, the user transaction recording device 28 

20 stores data representing the transactions that have been initiated with it. For example, a 
user goes to a merchant and makes multiple purchases with a smart card or other user 
transaction recording device. The smart card records the transaction detail data for all 
of the purchases at check-out. The data from the smart card is periodically uploaded 
into an application that resides on the user device 12 (via the interface device 1 10) and 

25 ultimately to the ASP 10 the next time the user logs in to the ASP 1 0, or on demand. 
The ASP 10 automatically loads the transaction data from the smart card into a user 
report according to the methods described above. The ASP 10 would also compare the 
transaction data it receives from the smart card with monthly credit card data to be sure 
it does not "double count" the transaction data received by the ASP 10 from another 

30 transaction data source, following the procedures described above. 
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Similarly, a user may enter "cash" transactions, i.e., those transactions in which 
cash was used to purchase goods or services. The user may enter the cash transactions 
either during a connection session with the ASP or during an off-line session, in which 
case the transaction data is uploaded at the next log in session. When entering a cash 
5 transaction, the user may select which category the e^qjenditure is assigned to, or the 
ASP may suggest a category based on the name of the merchant. 

Examples of other ways that off-line transaction data entered by a user into a 
user transaction device 28 or that a user submits to other third party financial (banking) 
service providers is received by the ASP 10 are described above in conjunction with 
10 FIG. 1. Transaction data (deposits, withdrawals, payments, etc.) firom these sources are 
also processed by the ASP 10 to be incorporated into a user report. 

FIGs. 10 and 1 1 illustrate still another feature according to the present 
invention. The ASP, in an attempt to obtain detailed transaction data firom a particular 
merchant (called a target merchant hereinafter), may send an email or present a web 
1 5 page to an end user that contains a message similar to that shown in FIG. 1 1 . The 
message achieves two fimctions: (1) to obtain directly from an end user sufficient 
information to categorize individual items purchased at a particular merchant that were 
not categorized to that level of detail by the ASP; and (2) to obtain permission fi-om the 
end user to petition or request detailed transaction data information from the merchant 
20 in order to automatically categorize transaction data to that level of detail. 

The ASP identifies a target merchant based on a variety of criteria, such as the 
spending behavior of a number of end users in step 140. In addition, each end user that 
frequently makes purchases at that target merchant is identified by searching through 
the transaction data of ASP end users. Once a target merchant is identified, the ASP in 
25 step 142 sends an email message or displays a particular web page during a connection 
session to an end user. The message is generated by the ASP and lists spending 
categories for products or services that can be purchased from a target merchant. As 
shown in FIG. 11, the message instructs the user to enter the approximate amounts (if 
not the exact amounts) that the end user spent on the various product categories at that 
30 merchant during a recent visit to that merchant that the ASP has processed (but not 
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previously processed to that level of detail). In step 144, the user enters amounts in the 
various categories. The message, if contained in an email, operates as a Java™ or otiier 
applet that can add and subtract as numbers are entered to reach a total amount. In step 
146, the user hits a "reply/send" button in the email message or a "submit" button on 
5 the web page to send the transaction data entered by the end user to the ASP to allow 
the ASP to categorize the transaction data to a more detailed level. 

Next, in step 148, contained within the message is a statement requesting for 
authorization from the user to add his/her name to a petition to have that target 
merchant automatically send detailed transaction data to the ASP thereby allowing the 

10 ASP to automatically categorize transaction data to a greater level of detail. The end 
user may check a box that gives the ASP the authority to include that user's name on a 
petition that will ultimately be presented to the target merchant. Step 148 may occur 
before step 146 to force the end user to reply to the request before sending or 
submitting the transaction data. In step 150, tiie ASP accumulates permissions from 

15 end users and eventually petitions the target merchant to receive detailed transaction 
data for tiiose end users that have given authorization to the ASP. 

Other features and functions that are provided by the ASP will be described in 
conjunction with FIGs. 12-17. Some of these features are provided as a result of the 
ASP's ability to track financial information of multiple users and compare information 

20 among end users. 

FIGs. 12-14 are examples of user interface screens generated by the ASP that 
display user report information in a variety of formats. FIG. 12 shows monthly 
comparison information for an end user. FIG. 13 shows detailed category information 
by month. FIG. 14 is a graphical comparison diagram of expenses by category. With 

25 reference to FIG. 12, the ASP will provide references (discount vendors, budget 
assistance, etc.) to an end user based information in a user report for an end user. 
The ASP may use a reference budget to compare an end user's actual spending/saving 
activity with a reference budget. The reference budget may be a user-determined 
budget, a budget set by the ASP, or an average or median budget for end users in 

30 similar income brackets. Moreover, in establishing a reference budget, the ASP may 
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adjust for factors such as income/spending bracket, the end user's geographic location 
or other demographic variables (age, race, family size, profession, household members, 
etc.). In addition, the budget suggested by the ASP is generated for multiple levels of 
savings rates, so that end user's can pace themselves with respect to savings and 
5 spending activity in order to meet the suggested budget. For example, for end users in 
similar income brackets and^or having other common factors, the ASP generates a 
suggested budget with monthly spending caps in a variety of spending categories. The 
reference budget may be determined from empirical data from outside sources or from 
data accumulated by the ASP across all or a portion of end users that subscribe to the 

10 ASP, or a combination thereof. Each month the ASP compares the end user's actual 
financial activity with the suggested budget. 

One use of the reference budget is if the end user is over budget across all 
categories or a specific category, the ASP provides certain tips or references for tips to 
the end user. One form of a reference is a hyperlink to the web site of one or more 

15 vendors, budget help resources, etc. For example, as shown at 400 in FIG. 12, if the 
ASP determines that an end user has expenses in a travel category that is more than 
some reference budget amoxmt, the ASP may list luiks to several discount travel sites. 
Similar references are shown at 410 in FIG, 13 in which case the ASP has determined 
that an end user has above average entertainment expenses and provides a list of 

20 discount entertainment resources. Likewise, FIG. 14 shows category information in 
graphical format and provides a link to budgetary resources as shown at 420. 

FIGs. 15 and 16 illustrate display screens that tihe ASP generates by comparing 
one end user's financial data with that of other end users and/or other data from outside 
sources. For example, the ASP may compare the financial information of end users in 

25 similar income brackets in order to provide meaningful advice to end users. FIG. 15 
shows comparisons between an end user's monthly budget and "The American 
Budget", i.e., an average budget of those in a similar income bracket. The ASP will 
identify to the end user those categories that are above the average as well as those 
categories that are better than the average, as shown at 440. Furihermore, wh&D. the 

30 ASP identifies for an end user a category that is better than the average, the ASP may 
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provide a message to that end user asking if that end user would be willing to share 
his/her spending tips/secrets with other end users in a similar income bracket. If so, the 
ASP would receive (via email or during a connection session a message) from that end 
user an explanation of the spending habits followed by that end user and share that 
5 information with other end users. FIG. 16 illustrates another example of how tibie ASP 
displays information that compares an end user's spending information with a reference 
budget. Also, end users may compare their financial information with other end users 
during electronic chat sessions. 

Still another feature is to provide a grade or score to an end user based on how 
10 well that end user's budget compares to a reference budget. 

Yet another feature is to provide spending opportunities to those end users who 
save a relatively large amoimt of money. These end users may, for example, be 
encouraged to make more expensive purchases for luxiuy type goods and/or services. 
The ASP may provide links to resources for such goods and/or services. 
15 Still another feature is to provide user interface or electronic chat rooms for end 

users in the same income bracket to share information directly with each other. 

FIG. 17 illustrates an example of a calendar function that the ASP provides for 
an end user to enable the end user to schedule bill payments and to view transaction 
information. The data displayed in the calendar is from multiple transaction data 
20 sources and automatically provides a unique view of financial information. 

Tlie above description is intended by way of example only and is not intended 
to limit the present invention in any way except as set forth in the following claims. 
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What is claimed is: 

1 . A method for automatically ttaddng financial activity for an end user, 
comprising: 

electronically receiving transaction data firom at least one transaction data 
source, the transaction data associated with an account of an end user; and 

automatically sorting the transaction data into categories based on identifier 
information in or associated with the transaction data. 

2. The method of clairn 1, and further comprising generating a report for an 
end user based on liie categories of transactions and making the report electronically 
accessible to the end user. 

3 . The method of claim 1 , wherein the step of electronically receiving 
comprises receiving transaction data firom a plurality of transaction data sources. 

4. The method of claim 3, and further comprising the end user identifying 
the transaction data sources firom which to receive transaction data for that end user. 

5 . The method of claim 3, and further comprising generating a report based 
upon transaction data from multiple accounts of an end user. 

6. The method of claim 1, and fiirther comprising notifying an end user 
when a transaction has not been automatically sorted in order to allow the end user to 
manually sort it. 

7. The method of claim 6, and wherein the step of notifying comprises 
notifying an end user with a message, and further allowing the end user to edit the 
information in the message to include category information to enable the transaction to 
be sorted according to information provided by the end user. 

8. The method of claim 1 , wherein the step of electronically receiving 
furflier comprises electronically receiving financial statement data for an end user 
including deposit transactions into an account of an end user. 

9. The method of claim 1 , wherein the step of electronically receiving 
further comprises electronically receiving financial statement data for an end user 
including withdrawals from an accomat of an end user. 
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10. The method of claim 1 , and further comprising the step of determining 
when a charge card transaction made by an end user has been reimbursed by detecting 
in the transaction data for an end user a corresponding deposit or credit into an account 
for that end user. 

1 1 . The method of claim 1, and further comprising the steps of detecting 
when transaction data received from two or more transaction data sources references the 
same data items for an end user so as not to double count the same transaction data. 

12. The method of claim 1 1 , wherein transaction data referencing the same 
data items is entered only once into a user report. 

13. The method of claim 1, wherein the step of automatically sorting is 
based upon merchant type identifier information included in or associated with the 
transaction data for a transaction. 

14. The method of claim 1 , wherein the step of automatically sorting is 
b^ed upon item type identifier information in or associated with the transaction data 
for a transaction. 

15. The method of claim 1, wherein the step of electronically receiving 
comprises receiving transaction data for a multi-item transaction conducted by an end 
user at a merchant, wherein the step of automatically sorting is based upon item type 
identifier infi>rmation included in the transaction data for the multi-item transaction. 

16. The method of claim 15, and further comprising steps of determining 
whether transaction data for a multi-item transaction has been previously processed as a 
single transaction by locating a transaction record that matches the multi-item 
transaction, and if so, replacing transaction information for the single transaction with 
transaction information for the multi-item transaction. 

17. The method of claim 1, and further comprising receiving off-line 
transaction data associated with a transaction of an end user. 

1 8. The method of claim 1 7, wherein the step of receiving off-hne 
transaction data comprises receiving transaction data stored in a user transaction 
recording device and relating to transactions made by an end user. 
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19. The method of claim 18, wherein the step of electronically receiving 
comprises receiving transaction data stored in the user transaction recording device 
from a processing entity that receives transaction data from the user transaction 
recording device. 

20. The method of clabn 1, and further comprising: 

identifying a target merchant where a particular end user has made transactions; 
providing information to the particular end user tiaat hsts categories for products 
or services; 

receiving data from the particular end user indicating amounts in the categories 
for expenditures made at the target merchant; and 

sorting the data for the particular end user into appropriate categories, 

2 1 . The method of claim 20, and fijrther comprising requesting authorization 
from the particular end user to seek permission to receive detailed transaction data from 
the target merchant for transactions made by the particular end user at the target 
merchant. 

22. The method of claim 1, wherein the step of electronically receiving 
comprises receiving transaction data associated with transactions made with a category- 
coded check, wherein the identifier information in the transaction data for the category- 
coded check comprises a category code. 

23. The method of claim 1 , wherein the step of automatically sorting 
comprises sorting transaction data corresponding to a transaction made with the 
category-coded check using the category code in the transaction data for the category 
coded check. 

24. The method of claim 1, wherein the step of electronically receiving 
comprises receiving transaction data from a user transaction recording device either 
directly from the user transaction recording device or from a processing entity that 
receives fransaction data from the user transaction recording device. 

25. An account service provider that tracks financial activity for a plurahty 
of end users capable of communicating with the account service provider, comprising: 
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a commumcation interface suitable for connecting with end user sites via a 
communications network and with at least one transaction data source; 

computing equipment coupled to the conamunication interface that 
electronically receives transaction data associated with at least one accoimt of an end 
user from the at least one transaction data source and automatically sorts the transaction 
data into categories based on identifier information in or associated with the transaction 
data; and 

a data storage coupled to the computing equipment to store transaction data for 
each of the plurality of end users. 

26. The account service provider of claim 25, wherein the computing 
equipment generates a report for an end user based on the categories of transactions and 
makes the report electronically accessible to an end user. 

27. The accoimt service provider of claim 25, wherein the computing 
equipment electronically receives transaction data from a plurality of transaction data 
sources. 

28. The account service provider of claim 27, wherein the computing 
equipment receives information from an end user to identify transaction data sources 
from which to receive transaction data for that end user. 

29. The account service provider of claim 27, wherein the computing 
equipment generates a report based upon transaction data from multiple accounts of an 
end user. 

30. The account service provider of claim 25, wherein the computing 
equipment notifies an end user when a transaction has not been automatically sorted in 
order to allow the end user to manually sort it. 

3 1 . The accoimt service provider of claim 30, wherein the computing 
equipment generates a message transmitted to the end user, and allows the end user to 
edit transaction data to include category information to enable the transaction to be 
sorted according to the information provided by the end user. 



wo 01/77933 



PCT/USOO/13716 



21 

32. The account service provider of claim 25, wherein computing equipment 
receives financial statement data for an end user including deposit transactions into an 
accoimt of an end user. 

33. The account service proAader of claim 25, wherein computing equipment 
receives financial statement data for an end user including withdrawals from an account 
of an end user. 

34. The account service provider of claim 25, wherein the computiag 
equipment determines when a charge card transaction made by an end user has been 
reimbursed by detectiiig in the transaction data for an end user a corresponding deposit 
or credit into an account for that end user. 

35. The account service provider of claim 25, wherein the computing 
equipment detects when transaction data received from two or more transaction data 
sources references the same data items for an end user so as not to double count the 
same transaction data. 

36. The account service provider of claim 35, wherein the computing 
equipment enters transaction data referencing the same data item only once into a user 
report. 

37. The account service provider of claim 25, wherein the computing 
equipment automatically sorts transaction data based upon merchant type identifier 
information in or associated with the transaction data for a transaction. 

38. The account service provider of claim 25, wherein the computing 
equipment automatically sorts transaction data based upon item type identifier 
information in or associated with the transaction data for a transaction. 

39. The account service provider of claim 25, wherein the computing 
equipment receives transaction data for a multi-item transaction conducted by an end 
user at a merchant, and automatically sorts the transaction data based upon item type 
identifier information included in the transaction data for the multi-item transaction. 

40. The account service provider of claim 39, wherein the computing 
equipment determines whether transaction data for a multi-item transaction has been 
previously processed as a single transaction by locating a transaction record that 
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matches the multi-item transaction, and if so, replacing transaction information for the 
single transaction with transaction information for the multi-item transaction. 

41 . The account service provider of claim 25, wherein the computing 
equipment receives off-line transaction data associated with a transaction of an end 
user. 

42. The account service provider or claim 41, wherein the computing 
equipment receives transaction data stored in a user transaction recording device and 
relating to transactions made by an end user. 

43 - The account service provider of claim 42, wherein the computing 
equipment receives transaction data stored in the user transaction recording device from 
a processing entity that receives transaction data from the user transaction recording 
device. 

44. The account service provider of claim 25, wherein the computing 
equipment identifies a target merchant where a particular end user has made 
transactions; provides information to the particular end user that hsts categories for 
products or services; receives data from the particular end user indicating amounts in 
the categories for expenditures made at the target merchant; and sorts the data for the 
particular end user into appropriate categories. 

45. The accoimt service provider of claim 44, wherein the computing 
equipment requests authorization from the particular end user to seek permission to 
receive detailed transaction data from the target merchant for transactions made by the 
particular end user at the target merchant. 

46. The account service provider of claim 25, wherein the computing 
equipment receives transaction data associated with transactions made with a categoiy- 
coded check, wherein the identifier information in the transaction data for the category- 
coded check comprises a category code, and automatically sorts transaction data 
corresponding to a transaction made with the category-coded check using the category 
code in the transaction data for the category coded check. 

47. The account service provider of claim 25, wherein the computing 
equipment receives transaction data from a user transaction recording device either 
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directly jBrom the user transaction recording device or from a processing entity that 
receives transaction data from the user fransaction recording device. 

48. The account service provider of claim 25, wherein the computing 
equipment generates user reports for a plurality of end users. 

49. The account service provider of claim 48, wherein the computing 
equipment generates average spending and or saving information for one or more 
categories across a plurality of end users. 

50. The account service provider of claim 49, wherein the computing 
equipment provides information to an end user with respect to category-specific 
spending of an end user. 

5 1 . The account service provider of claim 50, wherein the computing 
equipment provides suggestions to an end user to reduce spending in a category when it 
is determined that spending in that category for that end user is greater than a reference 
budget amoimt. 

52. The account service provider of claim 50, wherein the computing device 
provides a link to a web site of one or more vendors selected by the computing device 
that provide assistance to the end user to alter spending in that category. 

53. The account service provider of claim 52, wherein the computiag 
equipment provides names of one or more category specific vendors to an end user 
based upon the comparison of that end user's spending habits in a category with respect 
to spending habits across a plurality of end users in that same category. 

54. The account service provider of claim 25, wherein the computing 
equipment compares financial ioformation of end users based on a variety of factors, 
including one or more of income brackets, spending brackets, geographic location and 
demographics. 

55. The account service provider of claim 54, wherein the computing 
equipment displays information to an end user that illustrates comparison of financial 
activity of that end user compared to other end users having one or more comparable 
factors. 
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56. The accoimt service provider of claim 54, wherein the computing 
equipment requests permission from an end user determined to have relatively good 
spending habits in a particular category to share spending tips of that end user with 
other end users in a comparable income bracket 

57. The account service provider of claim 54, wherein the computing 
equipment displays a message to a first end user providing spending tips of second end 
user determined to have relatively good spending habits in a particular category for end 
users having one or more comparable factors. 

58. The account service provider of claim 54, wherein the computing 
equipment generates a reference budget for end users based on one or more comparable 
factors. 

59. The account service provider of claim 58, wherein the computing 
equipment generates a suggested budget for end users in similar income brackets and 
for end users that save money at similar rates. 

60. The account service provider of claim 49, wherein the computing 
equipment generates a grade or score for end users based on how they compare to other 
end users in one or more categories. 

61. The account service provider of claim 25, wherein the computing 
equipment detects when an end user is saving a relatively high amount of money and 
displays to the end user information for opportunities to spend money. 

62. The account service provider of claim 25, wherein the computing 
equipment generates a reference budget for an end user based on a variety of factors, 
including one or more of income brackets, spending brackets, geographic location and 
demographics. 
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1) UPDATE MY BUDGET NOW! 

SIMPLY CLICK THE REPLY BUHON TO THIS E-MAIL. AND FILL IN THE AMOUNTS FOR YOUR PURCHASES. 



MERCHAMTA - 6/14/2000 $242.16 
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* 
.1 
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BUDGET TIP-APPROXIMATE AMOUNTS ARE 
GOOD ENOUGH FOR BUDGETING PURPOSES. 
SO YOU DON'T NEED YOU RECEIPT IF YOU 
DON'T HAVE IT! 



«<PUT IN MISC/OTHER? <YES> 



2) HEIP AMERICAN HOUSEHOLDS BUDGET SMARTER ..... 
DID YOU KNOW THAT MERCHANTA COULD SEND YOU YOUR PURCHASE TRANSACTIONS AUTOMATICALLY 
INTO YOUR PERSONAL BUDGET? THEN YOU WOULD NOT HAVE TO FILL IN THE FORM ABOVE! IF YOU 
WOULD LIKE TO JOIN THE REST OF AMERICA IN ASKING MERCHANTA TO HELP AMERICANS BUDGET 
SMARTER. CUCK THIS BOX <YES> AND WE WILL ADD YOUR NAME TO THE PETITION TO HAVE 
MERCHANTA HELP YOU BUDGET BETTER! 

3) TAKE A LOOK AT YOUR BUDGET NOW! CUCK HERE TO TAKE ME TO <Mr AMERICAN BUDGEr> 

NOTE: THIS INFORMATION IS PRIVATE AND CONFIDENTIAL ANY USE OF THIS INFORMATION WITHOUT THE 
EXPRESS WRIHEN CONSENT OF THE PROVIDER IS FORBIDDEN BY LAW. ANY VIOLATION WILL BE 
PROSECUTED TO THE FUa EXTENT OF THE LAW ALLOWED. 
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DECLARATION AND POWER OF ATTORNEY 
FOR PATENT APPLICATION 

(X) Original ( ) Supplemental ( ) Substitute ( ) PCT 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my name. 

I believe I am an original, first and sole inventor (if only one name is listed below) or an original, first and 
joint inventor (if plural names are listed below) of the subject matter which is claimed and for which a 
patent is sought on the invention entitled "SYSTEM AND METHOD FOR AUTOMATED 
TRACKING OF FINANCIAL TRANSACTIONS," which is described and claimed in the 
specification 

(check one) [ ] which is attached hereto, or 

[ ] which was filed on , as United States Application No. and with amendments 

through (if applicable), or 
[X] in International Application No. PCT/USOO/ 13716, filed 1 7 May 2000, and as 

amended on (if applicable). 

I hereby state that I have reviewed and understand the contents of the above identified specification, 
including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose all information known by me to be material to the patentability of the 
claims of this application in accordance with Title 37, Code of Federal Regulations, §1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code §119 (a)-(d) or §365(b) of any 
foreign application(s) for patent or inventor's certificate, or §365(a) or §365(b) of any PCT international 
application which designated at least one country other than the United States of America, listed below 
and have also identified below, by checking the box, any foreign application for patent or inventor's 
certificate, or of any PCT international application having a filing date before that of the application on 
which priority is claimed: 



PRIOR FOREIGN APPLICATIONS: 

(ENTER BELOW IF APPLICABLE) 


PRIORITY CLAIMED 

(MARK APPROPRIATE BOX BELOW) 


APP. NUMBER 


COUNTRY 


DAY/MONTHA^EAR 
FILED 


YES 


NO 


PCTAJS00/n716 1 


PCT 


17Mfiv9000 - 


X 




PCTALSnO/090R9 


PCT 


6 April 2000 


X 





I hereby claim the benefit under Title 35, United States Code, § 1 19(e) of any United States provisional 
application(s) listed below. 
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APPLICATION NUMBER 


FILING DATE | 







T hereby claim the benefit under Title 35, United States Code, §120 of any United States application(s) 
listed below and, insofar as the subject matter of each of the claims of this application is not disclosed in 
the prior United States application in the manner provided by the first paragraph of Title 35, United States 
Code, §112, 1 acknowledge the duty to disclose all information known by me to be material to the 
patentability of the claims of this application as defined in Title 37, Code of Federal Regulations, §1.56 
which became available between the filing date of the prior application and the national or PCT 
international filing date of this application: 



APPLICATION 
SERIAL NO. 


FILING DATE 


STATUS 

(MARK APPROPRIATE COLUMN BELOW) 


PATENTED 


PENDING 


ABANDONED 























I hereby appoint the following attorneys and/or agent(s) to prosecute this application and to transact all 
business in the Patent and Trademark Office connected therewith: 




Address all telephone calls to 

Jennifer P. Medlin at telephone no. (404) 688-0770. 
Address all correspondence to: 

Jennifer P. Medlin 
NEEDLE & ROSENBERG, P.C. 
Suite 1200, The Candler Building 
127 Peachtree Street, N.E. 
Atlanta, Georgia 30303-1811 

I hereby declare that all statements made herein of my own knowledge are true and that all statements 
made on information and belief are believed to be true; and fiirther that these statements were made with 
the knowledge that willfiil false statements and the like so made are punishable by fine or imprisonment, 
or both, under Section 1001 of Title 18 of the United States Code and that such willfiil false statements 
may jeopardize the validity of the application or any patent issued thereon. 
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Full name of first inventor: Richard E. Pickering 

Inventor's signature: ^ D . 

Residence: 8280 SouJ^^^^errace, Duluth, GA 30097 

Post Office Address: same*^ residence ^A— 

Citizenship: U.S.A. 
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